Product Code Database
Email forwarding generically refers to the operation of re-sending a previously delivered e-mail to an email address to one or more different email addresses.
The term forwarding, used for mail since long before electronic communications, has no specific technical meaning,In section 3.9.2 List of RFC 5321, the term forwarding is used ambiguously. It notes that " the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the Return-Path ." That wording, new w.r.t. RFC 2821, could be interpreted as the definition of forwarding, if the same term weren't used at the beginning of the same subsection with the opposite meaning. As a contributor to RFC 5321 agreed, but it implies that the email has been moved "forward" to a new destination.
Email forwarding can also redirect mail going to a certain address and send it to one or more other addresses. Vice versa, email items going to several different addresses can converge via forwarding to end up in a single address in-box.
Email users and administrators of email systems use the same term when speaking of both server-based and client-based forwarding.
Email administrators sometimes use the term redirection as a synonym for server-based email-forwarding to different recipients. Protocol engineers sometimes use the term Mediator to refer to a forwarding server.
Because of Email spam, it is becoming increasingly difficult to reliably forward mail across different domains, and some recommend avoiding it if at all possible.
By contrast, the terms remailing or redistribution can sometimes mean re-sending the message and also rewriting the "envelope sender" field. Electronic mailing lists furnish a typical example. Authors submit messages to a reflector that performs remailing to each list address. That way, (which report a failure delivering a message to any list- subscriber) will not reach the author of a message. However, annoying misconfigured vacation autoreplies do reach authors.
Typically, plain message-forwarding does alias-expansion, while proper message-forwarding, also named forwarding tout-court serves for mailing-lists. When additional modifications to the message are carried out, so as to rather resemble the action of a Mail User Agent submitting a new message, the term forwarding becomes deceptive and remailing seems more appropriate.
In the Sender Policy Framework (SPF), the domain-name in the envelope sender remains subject to policy restrictions. Therefore, SPF generally disallows plain message-forwarding. In case of forwarding, the email is being sent from the forwarding server, which is not authorized to send emails for the original sender's domain. So the SPF will fail. Intra domain redirection complies with SPF as long as the relevant servers share a consistent configuration. Mail servers that practice inter-domain message-forwarding may break SPF even if they do not implement SPF themselves, i.e. they neither apply SPF checks nor publish SPF records.
Consider the following forward path:
Domain B must not plainly forward a message from domain A to domain C, unless it controls either the policy of A or the filtering of C. Indeed, if A publishes an SPF policy that prevents B from using A's name, and C applies sender's policy-checking, C may refuse the message according to RFC 7208. In other words, one cannot formally distinguish plain message-forwarding from illegal domain-name abuse.
Sender Rewriting Scheme provides for a generic forwarding mechanism compatible with SPF.
Forwarding as attachment prepares a MIME attachment (of type message/rfc822) that contains the full original message, including all headers and any attachment. Note that including all the headers discloses much information about the message, such as the servers that transmitted it and any client-tag added on the mailbox. The recipient of a message forwarded this way may be able to open the attached message and reply to it seamlessly.
This kind of forwarding actually constitutes a remailing from the points of view of the envelope-sender and of the recipient(s). The message identity also changes.
The concept at that time envisaged the elements of the forward-path (source route) moving to the return-path (envelope sender) as a message got relayed from one SMTP server to another. Even if the system discouraged the use of source-routing, See the note in section 6.2.7 Explicit path specification of RFC 822 dynamically building the return-path implied that the "envelope sender" information could not remain in its original form during forwarding. Thus RFC 821 did not originally allow plain message-forwarding.
The introduction of the MX recordMX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A. made source-routing unnecessary. In 1989, RFC 1123 recommended accepting source-routing only for backward-compatibility. At that point, plain message forwarding became the recommended action for alias-expansion. In 2008, RFC 5321 still mentions that "systems may remove the return path and rebuild it as needed", taking into consideration that not doing so might inadvertently disclose sensitive information. Plain message forwarding may disclose the final destination-address irrespectively of the user's intention. See sections 7.7 Information Disclosure in Message Forwarding, and 4.4 Trace Information in RFC 5321. Actually, plain message-forwarding can be conveniently used for alias expansion within the same server or a set of coordinated servers.
Email predates the formalization of client–server architectures in the 1990s.The book dates in ftp://ftp.uu.net/usenet/news.answers/client-server-faq.Z range from the early 1990s. Although remote procedure calls originated in the 1970s, they did not become widely used until networks became quite common. Therefore, the distinction between client and server seems necessarily forced. The original distinction contrasted daemons and user-controlled Computer program which run on the same machine. The sendmail daemon used to run with superuser privileges so it could impersonate any user whose mail it had to manage. On the other hand, users can access their own individual mail-files and configuration files, including ~/.forward. Client programs may assist in editing the server configuration-files of a given user, thereby causing some confusion as to what role each program plays.
|
|
